Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

test: fix parameters in test-repl.js #23609

Closed

Conversation

binaryme
Copy link
Contributor

@binaryme binaryme commented Oct 12, 2018

fixed order of parameters in assert.strictEqual() assertion functions,
first argument provided was the expected value and the second value
was the actual value.

this is backwards from the documentation for assertions like
assert.strictEqual() where the first value being tested and the second
value is the expected value

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • tests and/or benchmarks are included
  • commit message follows commit guidelines

fixed order of parameters in assert.strictEqual() assertion functions,
first argument provided was the expected value and the second value
was the actual value.

this is backwards from the documentation for assertions like
assert.strictEqual() where the first value being tested and the second
value is the expected value
@nodejs-github-bot nodejs-github-bot added the test Issues and PRs related to the tests. label Oct 12, 2018
@addaleax addaleax added repl Issues and PRs related to the REPL subsystem. fast-track PRs that do not need to wait for 48 hours to land. labels Oct 12, 2018
@BridgeAR BridgeAR added the code-and-learn Issues related to the Code-and-Learn events and PRs submitted during the events. label Oct 12, 2018
Copy link
Member

@ChALkeR ChALkeR left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

There are also assert.strictEqual(server, socket.server), but those are probably fine — I'm not sure if there is any order preference for those as both server and socket.server are returned and are two different «actual» values.

BridgeAR pushed a commit to BridgeAR/node that referenced this pull request Oct 15, 2018
fixed order of parameters in assert.strictEqual() assertion functions,
first argument provided was the expected value and the second value
was the actual value.

this is backwards from the documentation for assertions like
assert.strictEqual() where the first value being tested and the second
value is the expected value

PR-URL: nodejs#23609
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Сковорода Никита Андреевич <chalkerx@gmail.com>
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
Reviewed-By: Sakthipriyan Vairamani <thechargingvolcano@gmail.com>
BridgeAR pushed a commit to BridgeAR/node that referenced this pull request Oct 15, 2018
fixed order of parameters in assert.strictEqual() assertion functions,
first argument provided was the expected value and the second value
was the actual value.

this is backwards from the documentation for assertions like
assert.strictEqual() where the first value being tested and the second
value is the expected value

PR-URL: nodejs#23609
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Сковорода Никита Андреевич <chalkerx@gmail.com>
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
Reviewed-By: Sakthipriyan Vairamani <thechargingvolcano@gmail.com>
@BridgeAR
Copy link
Member

Landed in a039c86 🎉

@soyisraelortiz congratulations on your first commit to Node.js!

@BridgeAR BridgeAR closed this Oct 15, 2018
jasnell pushed a commit that referenced this pull request Oct 17, 2018
fixed order of parameters in assert.strictEqual() assertion functions,
first argument provided was the expected value and the second value
was the actual value.

this is backwards from the documentation for assertions like
assert.strictEqual() where the first value being tested and the second
value is the expected value

PR-URL: #23609
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Сковорода Никита Андреевич <chalkerx@gmail.com>
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
Reviewed-By: Sakthipriyan Vairamani <thechargingvolcano@gmail.com>
addaleax pushed a commit that referenced this pull request Oct 20, 2018
fixed order of parameters in assert.strictEqual() assertion functions,
first argument provided was the expected value and the second value
was the actual value.

this is backwards from the documentation for assertions like
assert.strictEqual() where the first value being tested and the second
value is the expected value

PR-URL: #23609
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Сковорода Никита Андреевич <chalkerx@gmail.com>
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
Reviewed-By: Sakthipriyan Vairamani <thechargingvolcano@gmail.com>
MylesBorins pushed a commit that referenced this pull request Oct 30, 2018
fixed order of parameters in assert.strictEqual() assertion functions,
first argument provided was the expected value and the second value
was the actual value.

this is backwards from the documentation for assertions like
assert.strictEqual() where the first value being tested and the second
value is the expected value

PR-URL: #23609
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Сковорода Никита Андреевич <chalkerx@gmail.com>
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
Reviewed-By: Sakthipriyan Vairamani <thechargingvolcano@gmail.com>
@codebytere codebytere mentioned this pull request Nov 27, 2018
rvagg pushed a commit that referenced this pull request Nov 28, 2018
fixed order of parameters in assert.strictEqual() assertion functions,
first argument provided was the expected value and the second value
was the actual value.

this is backwards from the documentation for assertions like
assert.strictEqual() where the first value being tested and the second
value is the expected value

PR-URL: #23609
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Сковорода Никита Андреевич <chalkerx@gmail.com>
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
Reviewed-By: Sakthipriyan Vairamani <thechargingvolcano@gmail.com>
MylesBorins pushed a commit that referenced this pull request Nov 29, 2018
fixed order of parameters in assert.strictEqual() assertion functions,
first argument provided was the expected value and the second value
was the actual value.

this is backwards from the documentation for assertions like
assert.strictEqual() where the first value being tested and the second
value is the expected value

PR-URL: #23609
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Сковорода Никита Андреевич <chalkerx@gmail.com>
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
Reviewed-By: Sakthipriyan Vairamani <thechargingvolcano@gmail.com>
@codebytere codebytere mentioned this pull request Nov 29, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
code-and-learn Issues related to the Code-and-Learn events and PRs submitted during the events. fast-track PRs that do not need to wait for 48 hours to land. repl Issues and PRs related to the REPL subsystem. test Issues and PRs related to the tests.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants